FIG. 1 (Prior Art) is a diagram that illustrates an operation of a network device loosely referred to as a transparent proxy 1. There are many variants of transparent proxy devices. The transparent proxy 1 illustrated in FIG. 1 is but one example. In one operational example, a client device 2 is part of a company network. An application layer program 4 running on the client device 2 wishes to transmit information out of the company network and across the internet to an application program 5 running on a server device 3. The application layer program 4 running on the client device 2 in this example is a web browser. The application layer program 5 running on the server device 3 in this example is a web server that serves email (i.e., a webmail server). The information to be exchanged is an email that browser 4 sends to web server 5 over an encrypted link.
A protocol processing stack 6 executes on the client device 2. A protocol processing stack 7 executes on the transparent proxy device 1. A protocol processing stack 8 executes on the server device 3. When a user uses the browser 4 to connect to the web server 5, the browser seeks to establish a TCP connection with an appropriate TCP destination port on the server device 3 so that the email can later be sent, in the form of payloads of a stream of TCP/IP packets, across the TCP connection from a source TCP port on the client device 2 to the destination TCP port on the server device 3. The TCP destination port is a TCP port associated with the web server program 5.
The protocol processing stack 7 executing in the proxy device 1, however, intercepts the client's attempt to establish the TCP connection and terminates the TCP connection on the proxy device 1, thereby establishing a first TCP connection 24 between the client device 2 and the proxy device 1. From the attempt to establish the connection received from the client device 2, the proxy device 1 learns the intended destination IP address of the server device 3 as well as the intended destination TCP port to which the client device 2 wishes to connect. The TCP processing layer of the protocol processing stack 7 executing in the proxy device 1 then initiates establishment of a second TCP connection 25 between the proxy device 1 and the TCP destination port on the server device 3. After the proxy device 1 has established the second TCP connection, information can be sent from the source TCP port on the client device 2 associated with the browser, across the first TCP connection 24 to the proxy device 1, up the stack 7 of the proxy device 1, back down the stack 7 of the proxy device 1, and then across the second TCP connection 25 from the proxy device 1 to server device 3, and up the stack 8 of the server device 3 to the desired TCP destination port of the web server application layer program 5. Similarly, application layer information can be sent in the opposite direction from the web server application program 5 executing on the server device 3, down the protocol processing stack 8 executing on the server device 3, across the second TCP connection 25 to the proxy device 1, up and down the stack 7 of the proxy device, and then across the first TCP connection 24 from the proxy device 1 to the client device 2, and up the stack 6 of the client device 2 to the application layer program 4.
To pass through the proxy device 1, the information passes up the protocol processing stack 7 of the proxy device to an application layer program 9, and then back down the protocol processing stack 7 of the proxy device and out of the proxy device. The application layer program 9 can examine the information. In one example, if information passing through the proxy device meets certain criteria, then the information is copied and is forwarded from the proxy device to a fourth device for storage and additional analysis. The existence of the proxy device 1 may be unknown both to the client device 2 and to the server device 3. Such a proxy device is therefore referred to as a transparent proxy.
FIG. 2 (Prior Art) is a simplified diagram that illustrates this operation in further detail. In the orientation of the diagram of FIG. 2, time extends in a downward direction. Initially, the browser 4 executing on the client 2 seeks to establish a TCP connection to the web server 5 executing on the server 3 so that the browser 4 can later send an encrypted email to the web server 5. The TCP protocol processing layer of the stack 6 causes the client 2 to transmit a SYNC segment. The SYNC segment contains the source IP address of the client 2 as well as the source TCP port associated with the browser program 4 executing on the client 2. The SYNC segment also contains the destination IP address of the server 3 as well as the destination TCP port on the server associated with the web server application layer program 5. The proxy 1, however, intercepts this SYNC segment and returns an acknowledgement segment ACKTC to the client as if the transparent proxy were the server. In standard fashion for establishing a TCP connection, the transparent proxy also transmits a SYNTC segment to the client, to which the client responds with an acknowledgement segment ACKC. The first TCP connection 24 is then established between the client device 2 and the proxy 1. This SYN, ACK and SYN, ACK handshake is illustrated in portion 10 of FIG. 2. Next, proxy uses the intended TCP and IP destination information in the original SYNC segment to establish the second TCP connection 25 between the proxy and the server. The proxy therefore issues a SYNTS segment, to which the server responds with an ACKS and SYNS. The proxy responds to the SYNS segment from the server with an ACKTS segment, thereby establishing the second TCP connection 25 with the server. This second SYNTS, ACKS and SYNS, ACKTS handshake is illustrated in portion 11 of FIG. 2. As illustrated in FIG. 1, flow control on the first TCP connection 24 between the client and proxy is managed by a first TCP control loop 12 involving a TCB 13 (Transmission Control Block) on the client and a TCB 14 on the proxy. Flow control between the proxy and the server is likewise managed by a second TCP control loop 15 involving a TCB 16 on the proxy and a TCB 17 on the server.
If the email were not to be sent over an encrypted link, then the next communication would be an HTTP request sent out from the client device, but because in this example the email being sent is to be sent over an encrypted link, the HTTPS protocol is used and a pair of SSL sessions must first be set up. The first SSL session is between the client and the proxy. The second SSL session is between the proxy and server. SSL session setup allows cryptographic parameters for a following SSL session to be exchanged, and allows the server device 3 to be authenticated. The SSL layer of the protocol stack 6 of the client 2 initiates the first SSL handshake by transmitting a CLIENT_HELLOC message that is destined for server 3. The SSL layer is located above the TCP layer but below the application layer of the protocol stack. The client and proxy exchange SSL messages to complete a four-way SSL handshake. Similarly, the proxy and the server exchange SSL messages to complete a four-way handshake. In the illustration of FIG. 2, the two four-way handshakes are occurring at the same time. The proxy has the option to modify any part of either handshake. As indicated in FIG. 2, a server certificate SERVER_CERTIFICATES is sent from the server to the proxy. The proxy uses information in SERVER_CERTIFICATES to authenticate the server. The proxy modifies the information in SERVER_CERTIFICATES to generate a SERVER_CERTIFICATET, which is different from SERVER_CERTIFICATES but has enough similarities to impersonate the server. The proxy sends the SERVER_CERTIFICATET to the client device. The client device 2 uses information in SERVER_CERTIFICATET to authenticate the proxy.
At this point, a policy stored on the proxy server can be applied to the SERVER_CERTIFICATES to determine how the information passing between the client and server is to be handled. This decision point is indicated in FIG. 2 with the large dot symbol 23. As a result of the SSL session setup process, the client device 2 has generated an SSL session cryptographic parameter set K1 and the server device 3 has generated an SSL session cryptographic parameter set K2. The SSL session cryptographic parameter sets K1 and K2 are later used by the client and server to send encrypted data payloads to each other during the SSL session.
After the two SSL four-way handshakes have been completed, the client device 2 can use its cryptographic parameter set K1 to send encrypted information to the server device 3 in the form of encrypted SSL messages. The notation EK1{HTTP GET} indicates that an HTTP GET application layer message is encrypted with the client's SSL session cryptographic parameter set (K1). The transparent proxy 1 receives the HTTP GET message in the form of several encrypted SSL messages. For each SSL message, the proxy returns an ACK to the client. Substantial time may be required for the proxy to receive and decrypt the SSL messages that carry the overall HTTP GET. Several TCP/IP packets may have to be held in the proxy before decryption of an SSL message can occur. If TCP/IP packets are delayed and not ACKed back to the client device, then operation of the TCP control loop between the client and proxy may be unduly disturbed. Due to the existence of the first TCP control loop 12, however, the packets that carry the HTTP GET can be ACKed, such that the payloads of these several packets are held in the proxy 1 until enough information is held an SSL message. The proxy 1 then uses cryptographic parameter set K1 to decrypt each SSL message. In the example of FIG. 2, the combined decrypted payloads of the SSL messages together form the HTTP GET application layer message from the client.
Once the HTTP GET application layer message has been recovered at the application layer 9 in the proxy, the application layer program 9 can analyze the message. The HTTP GET message is also broken back down into smaller blocks of data. Each smaller block is encrypted using the cryptographic parameter set K2 to form an SSL message. In the illustrated example, the notation EK2{HTTP GET} indicates the HTTP GET message is encrypted using the cryptographic parameter set K2. The HTTP GET message is sent from the proxy 1 to the server device 3 in the form of many encrypted SSL messages, where SSL messages are sent as TCP/IP packets. In the receiving server device 3, the TCP/IP packets pass up protocol stack 8 to form SSL messages. The SSL layer of step 8 decrypts the SSL messages. The resulting unencrypted SSL message payloads are assembled to form the HTTP GET application layer message. The communication of the payload information across the encrypted link is illustrated in portion 19 of FIG. 2.
As the information passes through the proxy, the information passes up the stack 7 to the application layer program 9 running on the proxy 1, and then back down the stack 7 and out of the proxy. The application layer program 9 of the proxy 1 has access to the application layer message in unencrypted form. If the application layer message meets certain criteria, then the transparent proxy 1 may cause certain of the information to be copied elsewhere for future reference and analysis.
In the present example, the HTTP GET message from the client 2 is a request that the web server 5 on server 3 return an HTML form. The web server 5 returns the HTML form in a HTTP RESPONSE communication. When browser 4 on client 2 receives the form, the user uses browser 4 to compose an email. After typing the email into a field of the form, the user selects the submit button. When the user selects the submit button on the form, the browser 4 causes the form to be transferred in an HTTP POST communication from the client device 2 across the TCP connections 24 and 25 to the webserver 5 executing on server device 3. The HTTP POST is communicated as the payloads of a stream of SSL messages to the transparent proxy 1. The HTTP POST passes up the stack 7 to the application layer 9 of the proxy, and then back down stack 7. The HTTP POST is communicated as the payloads of a stream of SSL messages from proxy 1 to the server device 3. The HTTP POST passes up stack 8 and is presented to the web server application 5.
In the present example, after successful receipt of the email by the web server application layer program 5 executing on server device 3, the application layer program executing on either the client or the server initiates termination of the TCP connection mechanism. In the illustrated example, browser program 4 executing on client device 2 causes the TCP protocol processing layer of stack 6 to transmit a FINC segment destined for the server device and the TCP port of the web server. The proxy 1, rather than forwarding the FINC segment, returns an ACKTC segment to the client along with a FINTC segment and in accordance with standard TCP protocol terminated the first TCP connection between the client and proxy. This is unknown to the server. After termination, the client does not know that there still exists a second TCP connection between the proxy and the server. Termination of the first TCP connection 24 is illustrated in portion 20 of FIG. 2. The proxy 1 then initiates termination of the second TCP connection 25 between the proxy 1 and the server device 3 by transmitting a second FINTS segment to the server device 3 and TCP port of the web server. The server device 3 returns an ACKS to the proxy along with a FINS segment. The proxy returns an ACKTS segment in accordance with standard TCP protocol to terminate the second TCP connection. After the standard TCP connection termination handshake has occurred, both TCP connections 24 and 25 are terminated. Memory resources on the client device, proxy device, and server device used to store the TCBs for the two TCP control loops may be reused for other purposes. Processing resources on the proxy device that would otherwise have to be used to maintain TCP connection state can be used for other purposes.
In the example of FIGS. 1 and 2, proxy 1 makes a determination at the time it receives the SYNC segment that the flows for the upcoming TCP connection are to be analyzed, and that this analysis will require that the two TCP connections 24 and 25 be established. The asterisk 22 in FIG. 2 indicates this decision point. By the time proxy 1 has received the actual SERVER_CERTIFICATES from the server device 3 and can confirm that an SSL session will in fact be established, the two TCP connections 24 and 25 have already been established. The two TCP connections, and the four associated TCBs 13, 14, 16 and 17 are used for communication between browser 4 and web server 5 until either the browser or web server initiates termination of a TCP connection.